|
|
|
|
|
|
|
reused over the long term. Contrary to the opinion that object-oriented methodologies take too long to rapidly develop software, object-oriented programming can indeed be fast. The main difference between OOP and non-OOP methods is that object technology generally treats applications and components as long-term capital assets of companies large and small. For individual programmers, OOP represents a better-organized way to reuse code in chunks called objects. |
|
|
|
|
|
|
|
|
Even in small, cozy environments where everyone knows your name, OTFP tends to represent wasted opportunities to save development costs in the long run. The resulting OTFP program is very dependent on both the original programmer and the programming language technology it uses at a point in time. This means two things: |
|
|
|
|
|
|
|
|
If the programmer dies or quits, the often undocumented program must be rewritten, and the person who usually rewrites it will likely use OTFP in order to satisfy rapid development requirements. |
|
|
|
|
|
|
|
|
If the technology becomes extinct or greatly changes (which happens often), the programmer will have to surf through the entire code base to find every reference to members of that technology (that is, API calls, object references, and so on). |
|
|
|
|
|
|
|
|
The unfortunate result of both these side effects is what is commonly referred to as spaghetti code. That is, OTFP generally (but not always) leads to a body of code that is disorganized and exclusively understood in the short term by the original programmer. In OTFP, all code is perfect to the original programmer, but beauty is in the eyes of the beholder. If you work in a small, informal environment, you can probably get away with OTFP because it takes far less analysis and design and might provide increased job security (which provides little benefit to the client). With this approach, though, there still remains the risk of changes in technology, as well as changes in user requirements now and in the future. In OTFP, you have to change every line of codewhich can be hundreds or thousands of linesto accommodate such changes. However, in OOP, you simply go to the object responsible for that technology or behavior and modify it accordingly, with little or no effect on the rest of the application code. |
|
|
|
|
|
|
|
|
In learning OOP, you'll likely use object technology in a team setting. On project teams, objects and groups of objects can be easily assigned to each member of a team as long as the objects' interfaces are well defined. This is one of the chief benefits of object technology. However, OTFP does not lend itself well to team development, in which a team can consist of two or more developers. The common response to this statement is, Well, there are only two developersFrank and I. We know each other well, and we just get together and hammer out our differences. This seldom works because of the following: |
|
|
|
|
|